[小ネタ] 同一のAWSアカウント内でスイッチロールする（マネジメントコンソール）

ちゃだいん

2020.09.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ちゃだいん（@chazuke4649）です。

勝手な思い込みで「スイッチロールは異なるアカウント間のみ可能で、同一アカウント内ではできない」と思ってたのですが、普通に同一アカウント内でもスイッチロールは可能でした。

確かに公式ドキュメントにも以下のような記載がありました。

ロールは、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、AWS Identity and Access Management (IAM) のユーザーに似ています。ユーザーとしてサインインすると、特定の一連のアクセス許可が付与されます。ただし、ロールにはサインインされませんが、一度サインインするとロールを切り替えることもできます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも他の AWS アカウントのロールでもかまいません。ロール、その利点、作成方法の詳細については、「IAM ロール」と「IAM ロールの作成」を参照してください。

引用元：ロールへの切り替え (コンソール) - AWS Identity and Access Management

同じような思い込みをしている人が他にもいるかもと思い、小ネタにはなりますがご紹介します。

そもそもなぜ他のアカウントじゃないと思っていたのか？

自分の勝手な思い込みの原因としては、おそらくIAMロール作成時のウィザードが原因かと個人的には思っています。

IAMコンソールからIAMロールを作成する際、下図画面をよく見ると思いますが、ここでは「別のAWSアカウント」と記載されています。ですがこれはあくまで主なユースケースといった表示理由と考えられ、「同一のAWSアカウント」を指定することも可能です。

参考記事

スイッチロールについての詳細は、以下エントリがわかりやすいのでご覧ください。

IAMのスイッチロールを理解したい | Developers.IO

スイッチロールしたAWSコンソールのセッション時間を1hよりも長くできるようになったので、スイッチロールの有効期限をおさらいする | Developers.IO

複数のIAM Userがあるアカウントをスイッチ元として、クロスアカウント用IAM Roleを作る | Developers.IO

実際にやってみる

構成図

極めてシンプルな構図ですが、念のため作成しました。

手順

IAMユーザーを作成する
IAMロールを作成する
スイッチロールする

1.IAMユーザーを作成する

今回は、111222333444アカウントにxxx-yamada.taroというIAMユーザーを作成します。 IAMユーザーの作成方法は割愛します。

このIAMユーザーはスイッチロールする権限が必要であるため、少なくとも以下のIAMポリシーが必要になるかと思います。ここで、一般的なクロスアカウントのスイッチロールの場合は、Resourceの部分が異なるAWSアカウントのIAMロールのARNなどを入力することになります。今回は同一AWSアカウント内なので、同じAWSアカウントのIAMロールのARNを入力しています。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::111222333444:role/xxx-yamada.taro-role"
    }
}

2.IAMロールを作成する

IAMロールを作成する際に、２つのポリシーを作成することになります。

１つ目は信頼ポリシーで、これはスイッチロールするために、スイッチロール元のプリンシパル（IAMにおける主体のこと）から assumeroleされることを許可するポリシーとなります。
ここで、一般的なクロスアカウントでのスイッチロールの場合は、111222333444 のAWSアカウント番号が、スイッチ元の異なるAWSアカウント番号になるはずです。今回の場合は同じAWSアカウント内なので下記にようになります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111222333444:user/xxx-yamada.taro"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

２つ目はユーザーポリシーで、これは実際にIAMロールに許可したいサービスに対する権限です。例えばAdministratorAccsessや、ReadOnlyAccessなど管理ポリシーを中心に適用することになるかと思います。今回はAdministratorAccessをアタッチすることにします。